ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group93a.txt/000025_icon-group-sender _Sun Jan 17 08:01:24 1993.msg

Internet Message Format | 1993-04-21 | 6KB

Received: by cheltenham.cs.arizona.edu; Sun, 17 Jan 1993 09:11:43 MST
Date: 17 Jan 1993 08:01:24 -0600 (CST)
From: Chris Tenaglia - 257-8765 <[e-mail]>
Subject: RE:entab/detab
To: [e-mail]
Message-Id: <[e-mail]>
Organization: Medical College of Wisconsin (Milwaukee, WI)
X-Vms-To: IN%"[e-mail]"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Status: R
Errors-To: [e-mail]

> From:    IN%"[e-mail]" 16-JAN-1993 21:57:19.34
> To:    IN%"[e-mail]"
> Subj:    RE: entab/detab

> I use entab and detab quite a bit -- often the text I want to process
> is entabbed, and often I want to entab my output.
Kind of like my reason but in reverse. I guess some people have a use
for tabs.

> Interestingly, those routines once *were* library routines (in a
> slightly different form), and made it into the language somewhere
> around version 6.  Certainly they *could* be library routines, but this
> sort of operations is way faster as a primitive than if it were written
> in Icon.  I personally don't feel that it clutters up the language.
> It would be interesting to create a questionaire to determine which
> features are rarely used.  E.g. how often do you use string invocation,
> or PDCOs, or run-time error conversion to failure?
I think you'd find a pretty even mixture of all kinds overall. I never
use entab() or coexpressions. Someone else might understand coexpressions
and think they're the greatest thing since the byte.

> I think an interesting (significant) project would be to create a
> smaller but more extensible Icon.  The "real" Icon would just be a
> nucleus, and much of the functionality could be added using new
> yet-to-be-conceived extensibility features.  The extensibility
> cabilities would include

>     (a) "easy" addition of new primitives written in C (whatever
>         that means -- maybe without relinking the interpreter, or
>         at least with changes limited to one module.  Maybe dynamic
>         linking -- that seems to be a trend and is implemented in
>         popular platforms now.)
Many icon programmers are not computer science majors. Those of us whose
skill in C is little to none, need/use those added features the most, and
have the least chance of rolling our own.

Variant translators and personal interpreters sound cool in conversation,
but many of us don't have a clue as to what they can do for us.

>     (b) addition of new facilities written in Icon without creating
>         name conflicts.
>     (c) overloading of existing functions (like copy()) and
>         operators to handle new data types.
More vendors these days are segmenting their product lines. They tell you
this is to make the product more 'modular'. They tell you that you should
not have to pay for features you don't use, and this modularity will save
you all kinds of money because of that. (Where would unix be if we had to
buy C and tcp/ip and each utility as a separate line item?)

What happens is the stripped down core gets sold at the regular price,
every little value added feature becomes a line item. Now ICON is not
a profit driven item like C++ or WordPerfect or Netware. The part that
is unpleasant here is that code won't be as portable unless you ship
all your icon language enhancements with them, and maybe your enhancements
may not like my enhancements. By keeping what some consider a lot of
language bloating in a central version, icon can maintain maximum code
portability. And I'll let hardware improvements make up for the added
memory or speed requirements.

> Has anyone else out there had a similar fantasy?  Then things like
> entab, X-stuff, and maybe even string scanning could be "extensions".

I'd like to see a few things added to icon. Here's my wishlist:

          1) every to by
             First for these to work with reals, and maybe someday
             with any type. &next &prior &first &last to be used
             also for referencing when numbers may not be meaningful.
             This may also contribute toward true scanning features
             for lists, sets, tables, and files.

          2) User defined operator $ ?
             Maybe just the $ character or maybe $+. Maybe this is
             superfluous because procedures can do it all to. But,
             I think it's no more pathological than string invocation
             which already exists.

          3) Two way pipes
             I know this one is probably tricky. I'd like to open a process
             for read and write, then I'd only need one file handle
             for a piping dialog. I can also then completely control
             the process IO. If I open a process for write I can't
             directly read its output unless I redirect it to a file
             and read that in separately. This may not always be
             possible.

          4) OS independent files
             Since icon is now on VMS, Unix, MAC, DOS, IBM and each has
             a file system syntax for files, directories, and disks, it
             would sure be easier to write totally portable code if the
             icon language had a universal file system syntax. Then the
             backend interpreter/compiler would handle mapping this
             syntax to the file system of the target OS.

> -- Bob Alexander
> Metaphor Computer Systems     [phone]      [e-mail]
> ====^=== Mountain View, CA  ...{uunet}!{decwrl,apple}!metaphor!alex

Chris Tenaglia (System Manager) |  "The past explained,
Medical College of Wisconsin    |   the future fortold,
8701 W. Watertown Plank Rd.     |   the present largely appologized for."
Milwaukee, WI 53226             |   Organon to The Doctor
[phone]                   |
[e-mail]